개요

게이트웨이는 이스티오의 주요 리소스 중 하나로, 서비스 메시에 내외부들 드나드는 트래픽의 진입문을 설정 관리한다.
리소스로서의 게이트웨이를 알기 전에, north-south 트래픽을 처리하기 위해 실제로 배포하는 워크로드인 인그레스 게이트웨이, 이그레스 게이트웨이부터 봐야 한다.
리소스로서의 게이트웨이는 해당 워크로드를 관리하는 CRD에 불과하기 때문이다.

개념 정리

네트워크 토폴로지에서의 게이트웨이

게이트웨이는 말 그대로 어떤 네트워크의 진입 지점을 이야기한다.
가장 쉽게 이해할 수 있는 표현으로는 API 게이트웨이가 있겠다.
이스티오의 서비스 메시 환경에서 외부의 트래픽을 받거나 외부로 트래픽을 보내는 경로가 되는 지점을 게이트웨이라고 표현한다.
이스티오의 게이트웨이는 클러스터와 외부의 트래픽을 잇는 진입점으로서 기능한다.
외부 트래픽은 게이트웨이를 통해 들어오고, 이 게이트웨이에서는 트래픽의 정보를 확인한다.
그리고 클러스터 내부에 적절한 서비스로 트래픽을 전달해준다.
서비스의 응답 역시 이 게이트웨이를 통해서 나가게 된다.

이 게이트웨이에 대한 트래픽을 조금 세분화시키는 용어가 있는데, 이것이 바로 인그레스(ingress), 이그레스(egress)이다.
잘 정의된 게이트웨이로 들어오는 트래픽을 인그레스가 부르며, 보통 이 트래픽에 대한 응답이 돌아가는 과정까지 총칭한다.
(나가는 트래픽까지 포함하여 부를 때 인바운드라고 표현하기도 한다.)
반대로 이그레스는 게이트웨이를 통해 클러스터 외부로 나가는 트래픽을 말한다.

인그레스란 표현은 쿠버네티스 네트워크를 공부할 때 인그레스 리소스로서 익숙할 것이다.
쿠버 리소스로서 인그레스 역시, HTTP관련 클러스터로 들어온 트래픽을 처리하는 진입점에 대한 설정을 하기에 그런 이름으로 명명된 것이다.

가상 IP, 가상 호스트

그렇다면 게이트웨이로 요청을 보내려면 어떻게 해야하고, 게이트웨이는 어떻게 트래픽을 적절한 서비스로 전달하는가?
여기에서 쓰이는 개념이 가상 IP, 가상 호스트이다.

사실 별 건 아니고, 게이트웨이가 가지는 IP를 가상 IP라고 부르고, 게이트웨이가 처리하는 호스트 이름을 가상 호스트라고 부른다.
왜 가상이라 부르는가?

이건 클러스터 외부의 클라이언트 입장에서 IP와 호스트를 봤을 때 가상이라 그런 것이다.
클라이언트가 통신하고자 하는 대상은 사실 게이트웨이 뒷단의 서비스인데, 요청을 보내기 위해서는 게이트웨이를 거쳐야 한다.
그래서 클라이언트는 게이트웨이의 주소로 요청을 보내게 되는데, 이것은 실제 서비스의 주소는 아니기에 가상 IP라고 부른다.
호스트 역시 마찬가지다.
게이트웨이는 들어온 요청의 호스트 헤더에 따라 트래픽을 어떻게 처리할지 결정한다.
물론 클러스터 내에서 뒷단의 서비스를 매칭하기 위해 각각이 호스트를 가지고 있을 것이고, 이 호스트가 클라가 요청한 호스트와도 일치하긴 할 것이다.
그러나 클라가 결국 호스트랍시고 요청한 대상은 게이트웨이이며, 게이트웨이가 해당 호스트인 마냥 처리한다.

결국 외부 클라의 요청의 정보들은 실제 서비스를 나타내고 있지 않음에도 게이트웨이가 요청을 받고, 처리하기 위해 쓰인다.
이러한 면에서 기본적인 IP와 호스트의 의미가 변질되어 일종의 추상화가 이뤄진다고 볼 수 있다.
그래서 게이트웨이가 처리하는 IP와 호스트를 아울러 가상 IP, 가상 호스트라고 표현하는 것이다.

그냥 개념적인 차원의 내용이긴 한데, 가상 호스트는 보통 뒷단에 어떤 서비스로 트래픽을 보낼지 정하는데 쓰인다.
그래서 이스티오를 설정할 때도 많이 등장하는 개념이라 알아두면 좋다.

인그레스 게이트웨이, 이그레스 게이트웨이

그럼 실제 게이트웨이는 쿠버네티스 클러스터에서 어떤 식으로 구현되는가?
간단하게, NodePort를 가진 서비스로 클러스터 외부에서 트래픽이 접근 가능하게 하고, 이 서비스의 백엔드로 프록시 서버를 두면 된다!
이스티오에서는 설정에 따라 이런 워크로드를 자동으로 배포해주는데, 이 워크로드를 인그레스, 이그레스 게이트웨이라고 부른다.
해당 게이트웨이 역할을 하는 워크로드 역시 하나의 프록시로, 엔보이가 배포된다.

리소스로서의 게이트웨이

이스티오 클러스터에서 게이트웨이의 실제 구현체는 엔보이 프록시를 담은 하나의 워크로드라는 것이 이제야 명확해진다.
그럼 이 게이트웨이에 여러 설정을 집어 넣으려면 어떻게 해야 하는가?
게이트웨이 구현체에 설정을 가하기 위해 이스티오에서는 Gateway라는 리소스를 정의해뒀다.
이를 통해 서비스 메시 클러스터에서 통합적으로 게이트웨이에 대한 관리를 할 수 있게 되는 것이다!
Gateway에 대한 리소스를 만들면 이스티오 컨트롤 플레인은 이를 해석하여 실제 게이트웨이 구현체에 설정을 반영한다.

여기에서 참고해야 하는 것이, Gateway 리소스를 만드는 것 자체는 실제 게이트웨이 구현체를 만드는 것과 별개이다.
이스티오의 Gateway 리소스는 이미 존재하는 게이트웨이 워크로드에 대해 설정을 하는 리소스이며, 워크로드 자체는 직접 배포해야만 한다.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  profile: default
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true

직접 배포해야 한다고 해서 어렵지는 않은 게, 이스티오 설치 및 관리를 하는 양식 파일에 이런 식으로 컴포넌트를 작성해두면 이스티오 컨트롤 플레인에서 알아서 해당 워크로드를 배포해준다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-user-gateway-injected
spec:
  selector:
    matchLabels:
      ingress: my-user-gateway-injected
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
        inject.istio.io/templates: gateway
      labels:
        ingress: my-user-gateway-injected
    spec:
      containers:
        - name: istio-proxy
          image: auto

이 방식은 게이트웨이API의 Gateway 리소스와 큰 차이점을 지닌다.
게웨api에서는 Gateway 리소스를 만들 시 해당 워크로드까지 같이 배포가 진행된다.
반면 이스티오의 Gateway 리소스는 먼저 외부 진입점으로서의 게이트웨이 워크로드가 있는 상태에서 게이트웨이 리소스를 만들어서 이를 추적 관리한다.

이그레스 게이트웨이에 대해 - ServiceEntry

여태 설명은 전부 인그레스에 대해 이야기했기에, 인그레스 게이트웨이를 배치하는 것은 상당히 자연스럽게 느껴진다.
그런데 이그레스의 경우는 어떨까?
이스티오에서는 모든 네트워크 트래픽이 프록시를 경유하기에 클러스터 외부로 나가는 트래픽에 대해서도 이 프록시 설정에 따라 동작하게 된다.

  meshConfig:
    outboundTrafficPolicy:
      mode: ALLOW_ANY

이스티오 설정 파일에서 이런 식으로 설정하면 프록시는 클러스터가 아닌 주소로 향하는 모든 트래픽을 허용해준다(기본값).
이걸 막고 싶다면 mode: REGISTRY_ONLY로 세팅하면 된다.
이렇게 막은 상황에서는 이스티오 외부로 나가는 트래픽은 반드시 이그레스 게이트웨이를 거쳐야만 한다.

이그레스에 대해서는 조금의 설정이 더 필요한데, 어떤 주소가 클러스터 외부에 해당하는 것인지를 명시해야 하기 때문이다.
서비스 메시에서 각 프록시는 서비스 레지스트리를 통해 자신이 요청을 보낼 주소를 알아낸다.
그래서 외부의 주소를 서비스 레지스트리에 등록한 후에, 비로소 이그레스 게이트웨이를 경유해 트래픽이 나가도록 할 수 있다.
이때 사용되는 리소스가 바로 Istio ServiceEntry인데, 설정법은 문서 참고.

양식 작성법

이제 이스티오 게이트웨이 양식을 어떻게 쓰는지 알아본다.

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: some-config-namespace
spec:
  selector:
    app: my-gateway-controller
  servers:
  # https로 리다이렉트하며, 두 호스트 처리
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - uk.bookinfo.com
    - eu.bookinfo.com
    tls:
      httpsRedirect: true
  # https 트래픽 처리
  - port:
      number: 443
      name: https-443
      protocol: HTTPS
    hosts:
    - uk.bookinfo.com
    - eu.bookinfo.com
    tls:
      mode: SIMPLE # tls 터미네이션 수행
      serverCertificate: /etc/certs/servercert.pem
      privateKey: /etc/certs/privatekey.pem
  # 네임스페이스 제한
  - port:
      number: 9443
      name: https-9443
      protocol: HTTPS
    hosts:
    - "bookinfo-namespace/*.bookinfo.com"
    tls:
      mode: SIMPLE
      credentialName: bookinfo-secret # 쿠버 시크릿로부터
  # 몽고 db 트래픽 처리
  - port:
      number: 2379
      name: mongo
      protocol: MONGO
    hosts:
    - "*"

기본적으로는 먼저 어떤 로드밸런서의 데이터를 처리할지 라벨 셀렉터 방식으로 지정한다.^[1]

servers

그 다음 servers 필드를 통해 게이트웨이에 대한 서비스 메시 내 설정들을 할 수 있다.
여기에서 사용될 수 있는 필드는 다음과 같이 정리할 수 있다.

• name - 이 프록시 설정의 이름
• port - 말 그대로 어떤 포트로 들어온 트래픽을 처리할지
  • 하위 필드 protocol에 가능한 값은 여러 개가 있다.
  • HTTP, HTTPS, GRPC, GRPC-WEB, HTTP2, MONGO, TCP, TLS
  • TLS로 설정하면 암호화된 트래픽을 그대로 백엔드로 패스스루해준다.
• hosts - 게이트웨이가 처리할 호스트
  • 네임스페이스/호스트와 같은 식으로 작성하면 호스트로 들어온 트래픽을 받기는 하는데, 특정 네임스페이스의 호스트로만 트래픽을 보내도록 강제할 수 있다.
  • 와일드카드 가능.
• bind - 게이트웨이가 트래픽을 받을 ip나 unix 소켓
  • x.x.x.x 형식으로 하면 ip, unix://path 형식으로 하면 유닉스 소켓을 받을 수 있다.
  • 유닉스 소켓으로 하면 포트는 0으로 설정돼야 한다.
• tls - TLS 관련 설정

servers.tls

    tls:
      mode: SIMPLE
      credentialName: bookinfo-secret

여기에서 tls 연결 모드를 지정할 수 있다.
모드의 종류는 다음과 같다.

• SIMPLE - 기본적인 tls 처리로, 게이트웨이에서 데이터를 복호화하여 백엔드로 전달한다.
• PASSTHROUGH - 클라헬로 과정의 SNI 필드를 호스트로 삼아 뒷단의 virtual service로 트래픽을 바로 보낸다.
• AUTO_PASSTHROUGH - SNI 필드에 매칭되는 virtual service 없어도 알아서 SNI 필드 구성후 업스트림으로 보냄
  • 이스티오 기반의 mTLS 통신을 하는 클러스터 내외부의 트래픽을 처리할 때 사용된다.
• MUTUAL - mTLS로, 뒷단의 서비스의 인증서를 기반으로 작동
• ISTIO_MUTUAL - mTLS인데 게이트웨이가 서비스 메시 내에서 가지는 인증서를 사용한다.
  • 이 모드로 사용하면 다른 필드는 전부 비어 있어야 한다.
• OPTIONAL_MUTUAL - mTLS를 기본으로 하나 클라의 인증서가 없으면 그냥 TLS 통신

SIMPLE, PASSTHROUGH, MUTUAL 정도가 기본이다.
게이트웨이에서 TLS 터미네이션을 하기 위해서는 기본적으로 서비스단의 인증서가 필요하다.

      serverCertificate: /etc/certs/servercert.pem
      privateKey: /etc/certs/privatekey.pem
---
      credentialName: bookinfo-secret

위와 같이 경로로 제공하거나, 쿠버네티스의 시크릿 리소스를 명시해주면 된다.

    tls:
      httpsRedirect: true

http 포트에서 https로 301 리다이렉트할 때는 이렇게 넣어준다.

관련 문서

참고